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UNIVERSAL CONTROLLER AND GRAPHICAL USER INTERFACE 

BACKGROUND OF THE INVENTION 
The present invention relates to a controller for multiple test instruments, and 
more particularly to a graphical user interface (GUI) for a controller that is configured to 
5 operate with a number of different test instruments. 

In the telecommunications industry, as well as in other industries, there are 
many different kinds of test instruments for performing various diagnostics. Most of the more 
recently developed test instruments employ a GUI with an input device such as a keyboard or 
touch screen. The output of the GUI in such instruments is presented to the user on an output 

10 mechanism such as a liquid crystal display (LCD). The GUI typically displays functions of 
the test instrument in a symbolic or graphical formal that the user can select via the input 
device. Each function is typically represented by at least a symbol and possibly text as well, 
rather than by text alone. This type of interface has been shown to make understanding and 
learning about the operation of the test instrument easier. 

1 5 When a function is selected in the GUI by the user, it generally causes a test or 

measurement to be performed by the test portion (i.e., test processor) of the instrument. The 
results of the test or measurement are then provided to the GUI portion (i.e., GUI processor) 
for presentation to the user on the display. To achieve this function, the GUI processor 
executes software that converts the user's selection into a specific test request or command 

20 that is executed by the test processor. This function is performed whether the test processor 
and GUI processor are integrated into the same instrument, or whether the test instrument is 
controlled by an external instrument such as a handheld computer or the like which 
communicates with the test instrument through a communications link such as a wired or 
wireless link, for example. In either case, the software associated with the GUI processor is 

25 pre-programmed to work with the specific test instrument that is to be controlled. 

The ability to perform multiple different test functions has been provided in 
existing devices by integrating all of the test functions into a single device and pre- 
programming a processor to control those test functions. An example of this type of device is 
the Dynatel™ 965DSP Subscriber Loop Analyzer manufactured by 3M Corporation of St. 
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Paul, Minnesota. Other devices that include hard-coded processors controlling test functions 
may be found in the telecommunications and automotive diagnostics industries, for example. 
BRIEF SUMMARY OF THE INVENTION 
While the existing approach to control of test instruments has been effective to 
5 control a single instrument with a single test processor, it would be useful to provide a 
common GUI that controls multiple test instruments. This would allow users, repair 
technicians and engineers to become familiar and skilled with a single GUI and associated 
processing hardware and software, and would provide a great deal of flexibility to a user who 
uses multiple test instruments by operating the instruments with a single controller. In 
1 0 addition, the cost of integrating an entire suite or multiple suites of test functions into a single 
device can be alleviated by using test devices that provide smaller sets of test functions 
controlled by a common controller and a common GUI. 

A graphical user interface (GUI) processor controls one of multiple different 
test devices. A user provides instructions via an input interface. The GUI processor includes 
15 a translator that is coupled to the input interface to receive the instructions input by the user. 
The translator may also receive a signal indicative of the type of test processor connected to 
the GUI processor. The instructions input by the user are translated into test device 
commands based on the type of test device that is connected to the GUI processor. The test 
device commands are transmitted to the test device, and test results are received from the test 
20 device and converted into display controls. A display engine is coupled to receive the display 
controls and to cause a display to display the test results. In one embodiment, the display is 
adjustable based on the type of test device to only provide the user with options that 
correspond to the capabilities available on the test device. 

BRIEF DESCRIPTION OF THE DRAWINGS 
25 FIG. 1 is a diagram of an existing test instrument having an integrated 

graphical user interface (GUI). 

FIG. 2 is a diagram of an existing test instrument having a separate control 
module and GUI. 

FIG. 3 is a diagram of an exemplary GUI processor that is operable to interact 
30 with a plurality of different test devices/processors. 
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FIG. 4A is a flow diagram illustrating an exemplary method of translating GUI 
commands into test processor commands. 

FIG. 4B is a flow diagram illustrating an exemplary method of converting test 
processor measurement results into GUI display commands. 
5 FIG. 5 is a diagram illustrating an exemplary hand-held computer that includes 

a GUI processor for controlling telecommunications test devices. 

FIG. 6 is a diagram of an exemplary telecommunications test device that 
includes a test processor and circuitry for performing one or more test functions on a 
communications cable. 

10 FIG. 7 A is a diagram illustrating an exemplary GUI display for a test device 

having a first set of test capabilities. 

FIG. 7B is a diagram illustrating an exemplary GUI display for a test device 
having a second set of test capabilities. 

FIGS. 8A-8H are diagrams illustrating exemplary GUI display screens for the 

1 5 test functions that can be performed by a communications test device. 

DETAILED DESCRIPTION 
FIG. 1 is a diagram of test instrument 10 having an integrated graphical user 
interface (GUI). Test instrument 10 includes test processor 12, GUI processor 14, display 16 
and an input device such as keypad 18. Test processor 12 performs a test of some kind, and 

20 communicates with GUI processor 1 4 by receiving test commands from GUI processor 1 4 and 
transmitting test results to GUI processor 14. GUI processor 1 4 interprets the test results and 
formats them appropriately for viewing on display 16. Keypad 1 8 serves as an input device 
that allows a user to input instructions that are formatted by GUI processor 14 into the test 
commands that are sent to test processor 12. 

25 FIG. 2 is a diagram of existing test instrument 20 having a separate control 

module and GUI. Test instrument 20 includes test processor 22, and separate control module 
23 includes GUI processor 24, display 26 and an input device such as keypad 28. Test 
processor 22 performs a test of some kind, and communicates with GUI processor 24 (via a 
wired or wireless link) by receiving test commands from GUI processor 24 and transmitting 

30 test results to GUI processor 24. GUI processor 24 interprets the test results and formats them 
appropriately for viewing on display 26. Keypad 28 serves as an input device that allows a 
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user to input instructions that are formatted by GUI processor 24 into the test commands that 
are sent to test processor 22. 

In both of the instrument configurations shown in FIGS. 1 and 2, the GUI 
processors are specifically programmed and configured to communicate with the individual 
5 test processors of the test instruments. If a different test processor were to be connected to the 
GUI processor, additional programming and configuration would be required for the system to 
operate properly. In other words, if the test processor of the types shown and described in 
FIGS. 1 and 2 were modified to delete or include other test functions, or if a new test 
processor were substituted, the GUI processor would also have to be modified to 

10 accommodate the changes. 

FIG. 3 is a diagram of exemplary GUI processor 30 that interacts with a 
plurality of different test devices and their associated processors. GUI processor 30 includes 
test processor dependent translator 32, common graphical display engine 34, and an input 
device interface such as keypad interface 36 for receiving input signals. Test processor 

15 dependent translator 32 receives a test processor select signal that indicates the type of test 
processor that is connected to GUI processor 30. The test processor select signal may be 
generated by signal communication and logic capability in GUI processor 30 that receives a 
signal from the connected test processor and determines the processor type, or may be 
provided in another manner such as in response to manual input by a user, for example. 

20 Common graphical display engine 34 also receives the test processor select signal to provide 
the capability to adjust the appearance of the display based on the type of test processor that is 
connected to GUI processor 30. For example, common graphical display engine 34 may 
receive information from the test processor select signal that indicates what types of 
measurements are able to be made by the device and its associated test processor, and may 

25 adjust the appearance of the display to show only the available types of measurements as 
options for the user to select. 

Test processor dependent translator 32 translates data received from a test 
processor and encodes commands for execution by the test processor, and also converts test 
results received from a test device into display commands, according to the flow diagrams 

30 shown in FIGS. 4A and 4B. Although test dependent processor 32 has been shown as a single 
functional block in FIG. 3, it will be understood by those skilled in the art that the translation 
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of user inputs and the conversion of test results from a test device can in some embodiments 
be performed by different structural components. As shown in FIG. 4A, a command input is 
initially received at block 40 from the user, indicating that a measurement is to be made by the 
test unit being utilized. If the device is adapted as described above to determine and display 
5 the types of tests that can be run by the test unit, then the input from the user at block 40 could 
be the user's selection of a test from the displayed tests available. The type of test unit is 
determined at block 42. As discussed above, this determination may be automatically made 
by signal communication and logic circuitry of the GUI processor that queries the test unit for 
information about its make and model, or may be made manually such as by an input from the 

1 0 user in response to a query, for example. Once the test unit type is determined, the command 
input by the user (also referred to as a GUI command) is translated by the test dependent 
processor into a test unit command, according to the type of test unit employed. In the 
embodiment illustrated by FIG. 4A, three types of test units (A, B and C) are available. It will 
be understood by those skilled in the art that any number of test unit types may be 

1 5 accommodated. The GUI command is converted to a type A test unit command at block 44 if 
the test unit is determined to be a type A unit, is converted to a type B unit command at block 
46 if the test unit is determined to be a type B unit, and is converted to a type C unit command 
at block 48 is the test unit is determined to be a type C unit. The translated command is then 
sent to the test unit at block 50, and the test unit makes the measurement commanded. 

20 The translation of GUI commands into test unit commands may be 

accomplished in a number of ways. In one exemplary embodiment, lookup tables are 
employed that are addressable by an index (the GUI command). Unique lookup tables are 
maintained for each type of test unit available. For the example of FIG. 4A, three lookup 
tables are maintained, for test unit types A, B and C, respectively. Each lookup table contains 

25 all of the possible commands that may be executed by the particular test unit type. Exemplary 
entries in a lookup table for a device operable to measure parameters related to the tip (T), ring 
(R) and ground (G) conductors of a communications cable are shown below in Table 1 . 
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TABLE 1 



Index (GUI Command) 


Test Unit Command Output 


VOLTS-TR 


V-TR 


VOLTS-TG 


V-TG 






OHMS-RG 


O-RG 



The entries shown in Table 1 are in a format that is customized for the GUI software that is 
5 being used and for the particular test device that is connected. Other test devices may require 
commands in a different format, such as a binary format, for example. GUI processor 30 
translates the GUI commands into the format that is appropriate for the test device being used. 

In another exemplary embodiment, a logic-based solution may be employed, 
such as decision tree logic that compares the GUI command entered by the user to all of the 

10 possible choices and selects the appropriate test unit command based on the results of the 
comparison. An example of a programming statement that could be utilized to execute this 
logic is the Switch-Case statement in the C programming language. Other variations of the 
logic-based solution will be apparent to those skilled in the art. For example, if the input 
provided by the user does not exactly match the name or description of a test that the test 

15 device is capable of running, then the device can either translate the GUI command into 
commands that will operate the test unit most closely related to the test requested, or prompt 
the user to select from among one or more tests the one that is desires, or take other action(s), 
depending on how the device is configured. 

FIG. 4B illustrates the process of transmitting measurement results from the 

20 test unit to the GUI processor. A measurement response from the test unit is initially provided 
as indicated at block 60. In some embodiments, the test unit continuously streams 
measurement results until an idle command or another measurement command is received. In 
other embodiments, the test unit performs the commanded measurement once, returns the 
result and becomes idle. It is also possible for different measurements performed by a single 
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device to be continuous and others to be performed once, as appropriate for the particular 
measurement being performed. The type of test unit is determined at block 62, similar to the 
manner described above, or may already be known to the device based on preceding steps. 
The response from the test unit is then translated into a format suitable for controlling the 
5 graphical display (also referred to as common GUI format). In the embodiment illustrated by 
FIG. 4B, test unit types A, B and C are again available. The test unit response for a type A 
test unit is converted to a common GUI format at block 64, the test unit response for a type B 
unit is converted to a common GUI format al block 66, and the test unit response for a type C 
test unit is converted to a common GUI format at block 68. The converted test unit response 

10 is then sent to the GUI control circuitry (such as common graphical display engine 34, FIG. 3) 
at block 70, to display the results of the measurements taken by the test unit. 

The conversion of test unit measurement responses into display commands 
may be accomplished in a number of ways, similar to the discussion of the translation of GUI 
commands into test unit commands above. In one embodiment, lookup tables are employed 

15 that are addressable by an index (i.e., the test unit measurement response). Unique lookup 
tables are maintained for each type of test unit available. For the example of FIG. 4B, three 
lookup tables are maintained, for test unit types A, B and C, respectively. Each lookup table 
contains all of the possible measurement responses that may be returned for the particular test 
unit type. Exemplary entries in a lookup table for a device operable to measure parameters 

20 related to the tip (T), ring (R) and ground (G) conductors of a communications cable are 
shown below in Table 2. 



TABLE 2 



Index (Measurement) 


Output to GUI 


V-TR-XX.X 


XX.X V 


V-TG-XX.X 


XX.X V 






O-RG-XX.XK 


XX.X KOhms 
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The entries shown in Table 2 are in a format that is customized for the GUI software that is 
being used and for the particular test device that is connected. Other test devices may produce 
measurement results in a different format, such as a binary format. GUI processor 30 
translates the test device measurement results into the appropriate GUI software format, 
5 regardless of the measurement result format. 

Example 

An example of a common GUI controller (a hand-held computer) for 
controlling multiple different communications test devices, test processors, and GUI are 
shown and described in FIGS. 5, 6, 7A, 7B and 8A-8H. 

10 FIG. 5 is a diagram of exemplary hand-held computer 72 that includes a GUI 

processor such as GUI processor 30 described above with respect to FIG. 3. Hand-held 
computer 72 includes housing 74, display 76 having a touch sensitive screen, and keypad 78. 
A user may input instructions via the touch sensitive screen or via keypad 78. Display 76 
shows an exemplary results screen for a resistance measurement function. 

1 5 Hand-held computer 72, via its GUI processor (described above with respect to 

FIG. 3), is equipped with the capability to communicate with multiple different test devices. 
Hand-held computer 72 is also equipped with the capability to communicate with a PC, such 
as a truck-mounted PC, to receive dispatch or other information via Bluetooth wireless 
communication, wired communication via an RS-232 serial link, or by other wired or wireless 

20 means. Alternatively, hand-held computer 72 could be equipped with a wireless LAN or 
WAN card to provide the capability to communicate with a server or other networked devices 
directly without using a PC. 

FIG. 6 is a diagram of exemplary communications test device 80 that includes a 
test processor and circuitry for performing one or more test functions on a communications 

25 cable. Test device 80 also includes an internal Bluetooth wireless interface and a serial 
interface for communication with hand-held computer 72 of FIG. 5. Other wired or wireless 
interfaces could also be provided. In most embodiments, test device 80 will not include its 
own display, since the display is provided by the GUI of the computer that is connected to 
control test device 80. This reduces the manufacturing cost of test device 80. 

30 FIG. 7A is a diagram illustrating exemplary GUI display 90a on hand-held 

computer 72 for controlling telecommunication test device 80 having at least nine different 



test capabilities (a full suite of "I&R" (installation and repair) communications tests). GUI 
display 90a provides a user with the options of selecting a voltage measurement (box 92), a 
current measurement (box 94), a resistance measurement (box 96), a "tool box 11 function (box 
98) for selecting options such as language setup, ohms-to-distance calculation, a load coil 
5 counter function, a ringer count function, etc., a function measuring the distance to an open on 
the cable pair (box 100), a tone function (box 102) for generating a sinusoidal tone on the 
connected conductors, a dB measurement function (box 104) for measuring signal loss, noise, 
power influence and pair balance, an Auto test function (box 1 06) for making a series of 
successive measurements on the connected conductors, or a kick test function (box 108). 

1 0 These measurement and function options are shown on GUI display 90a because the common 
graphical display engine detects that the test processor being used has all of these capabilities. 

FIG. 7B is a diagram illustrating exemplary GUI display 90b for an alternative 
test device having only five different test capabilities. GUI display 90b provides a user only 
with the options of selecting a voltage measurement (box 92), a current measurement (box 

1 5 94), a resistance measurement (box 96), a function measuring the distance to an open on the 
cable pair (box 1 00) or a dB measurement function (box 1 04) for measuring signal loss, noise, 
power influence and pair balance. The common graphical display engine does not display the 
options that are not available to the user, reducing the complexity and clutter of the GUI for 
operation by the user. Test options from which the user may select can be displayed in 

20 graphical form, alphanumeric form, or a combination of both (including one in which an 
alphanumeric description appears on the GUI when a cursor is placed over a graphic, for 
example). 

A user has the ability to select a desired test from the options listed on GUI 
display 90a (FIG. 7A) or 90b (FIG. 7B). As described above with respect to FIG. 4A, the user 
25 selects a test function (block 40), the test device type is determined (block 42), and the test 
function that is commanded is translated into an appropriate command for the type of test 
device that is being used (blocks 44, 46, 48). The translated command is then transmitted to 
the test device to perform the selected test (block 50) 

FIGS. 8A-8H are diagrams illustrating exemplary GUI display screens for a 
30 selection of test functions that can be performed by communications test device 80 (FIG. 6). 
FIG. 8 A illustrates GUI display screen 1 1 0 for measuring voltage between the tip (T), ring (R) 
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and ground (G) conductors of a communications cable. This test function can be initiated by 
selecting box 92 of the menu shown in FIG. 7 A. FIG. 8B illustrates GUI display screen 1 12 
for measuring loop current from a central office to a customer's premises. This test function 
can be initiated by selecting box 94 of the menu shown in FIG. 7A. FIG. 8C illustrates GUI 
5 display screen 114 for measuring the insulation resistance between conductors of the 
communications cable. This test function can be initiated by selecting box 96 of the menu 
shown in FIG. 7A. FIG. 8D illustrates GUI display screen 1 16 for measuring the capacitive 
length of a communications cable (also known as an "opens" measurement). This test 
function can be initiated by selecting box 100 of the menu shown in FIG. 7A. FIG. 8E 

10 illustrates GUI display screen 118 for initiation of a sinusoidal voice-band tone used to 
measure loss over a communications cable. This test function can be initiated by selecting 
box 102 of the menu shown in FIG. 7 A. FIG. 8F illustrates GUI display screen 120 for 
measuring the loss level of a tone (also known as a "dB" measurement). This test function can 
be initiated by selecting box 104 of the menu shown in FIG. 7A. FIG. 8G illustrates GUI 

1 5 display screen 1 22 for displaying the results of a sequence of predetermined tests to determine 
the overall health of a communications cable (also known as an "Auto test" measurement 
sequence). In the example shown in FIG. 8G, this test sequence includes voltage 
measurements, resistance measurements, "opens" measurements, a "loss" measurement and a 
"load coils" measurement, which are known in the art. The "Auto test" measurement function 

20 can be initiated by selecting box 106 of the menu shown in FIG. 7 A. FIG. 8H illustrates GUI 
display screen 124 for displaying the results of a "kick test," which is known in the art. This 
test function can be initiated by selecting box 1 08 of the menu shown in FIG. 7 A. 

The display screens shown in FIGS. 8A-8H are provided by converting 
measurement results from a test device into display commands, as described above with 

25 respect to FIG. 4B. The measurements are transmitted from the test device to the GUI 
processor (block 60), the test device type is determined (block 62), and the measurements are 
translated into an appropriate GUI format (blocks 64, 66, 68). The translated display 
commands are then provided to the GUI display (block 70). 

The test functions described above provide a suite of communications tests for 

30 a user, such as a cable installation and repair technician. Generally, a full suite of 
communications tests includes tests categorized as installation and repair, construction and 
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maintenance, cable maintenance, and special services. Other suites of test functions may be 
useful to provide in a test device, either as a limited set of functions within the full suite of 
tests (such as is shown in the reduced set of menu options of FIG. 7B) or as an entirely 
different suite of test functions. One example of other test functions are those provided by an 
5 optical testing module, which may provide the ability to perform an optical loss test, a light 
level/intensity test, and other functions. Further testing options that may be provided by a test 
device connected to a common GUI will be apparent to those skilled in the art. 

The common GUI provided by the present invention allows multiple types of 
test units to be controlled by a single device having a GUI with an appearance that can be 

10 made somewhat universal for all of the different devices. The GUI can also be adapted, 
within its general appearance, to only display options to the user that are available for 
performance by the particular test unit that is being used. These capabilities allow users to 
become familiar with a single GUI for controlling a number of different devices, which will 
improve the users' efficiency of operation, while reducing the complexity and potential for 

1 5 confusion to the user by only displaying options that are available for the particular type of test 
unit being used. In some embodiments, these capabilities are invisible to the user, provided 
by automatic interrogation performed by the common GUI controller to determine the 
capabilities of the test unit that is connected. 

The ability to control multiple different test devices is particularly appealing in 

20 the communications industry, where communications cables are being used to support a 
variety of different communication services, such as traditional voice service, digital voice and 
data services, video services, and others. Various suites of test functions can be provided by 
relatively low cost test devices, all of which can be controlled by a common hand-held 
computer with a common GUI. 

25 Although the present invention has been described with reference to preferred 

embodiments, workers skilled in the art will recognize that changes may be made in form and 
detail without departing from the spirit and scope of the invention. The invention can also be 
used in fields outside the communications field. 
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